Spring AI Tool Calling

1. 通用思想：它在 Agent 里是什么？

Tool Calling 本质上是 Agent 的“手”和“眼”。模型本身只会推理和生成文本，它既不能直接查数据库，也不能直接取消订单、发消息、写工单。Tool Calling 解决的就是：让模型表达调用意图，再由应用代它执行真实动作。

所以 Tool Calling 不是“模型真的会调接口”，而是：

1. 模型判断需要外部能力
2. 模型返回工具名和参数
3. 应用接手执行
4. 执行结果回填给模型
5. 模型基于新上下文生成最终回答

这也是 Agent 和普通聊天机器人拉开差距的关键能力之一。

2. Spring AI 落点：由哪些抽象和链路承载？

核心链路

Spring AI 中 Tool Calling 的主链是：

• 工具定义：名称、描述、JSON Schema
• 模型返回工具调用请求
• ToolCallingManager 负责找到对应工具并执行
• 工具执行结果作为 ToolResponseMessage 回填给模型
• 模型基于工具结果继续生成答案

工程价值

• Spring AI 自动帮你做了工具调用生命周期管理
• 工具参数 Schema 可以自动生成
• 方法、函数式 Bean 等都能映射成工具
• 可以配置 returnDirect，让某些工具执行后直接返回，不再回填模型

高频边界

• 工具描述不清，模型很容易不会调或乱调
• 默认参数都视为必填，若业务上是可选参数，必须明确标注，否则模型会瞎补值
• Tool Calling 是应用控制外部世界，不是把外部权限交给模型

3. 项目口径：在我的项目里怎么落地？

在我的 [[苍穹外卖AI客服]] 里，订单查询、取消订单、退款、FAQ 检索这些能力，本质上都属于 Tool Calling 的业务工具层。模型并不直接调用数据库或业务服务，而是先表达“我要调哪个工具、参数是什么”，再由 Java 后端去实际执行。

我在项目里重点控制了两件事：

1. 工具白名单不是全量暴露

   • 用户只是查 FAQ，就没必要把取消订单、退款工具都暴露出去
   • 只有识别到订单相关意图，才挂相关工具

2. 结果回填不能全靠自然语言

   • 工具执行结果要尽量结构化，便于后续步骤稳定使用
   • 对高风险结果，比如订单取消成功、退款成功，我不会只让模型读文字，而是让 Java 端同步解析并落库

所以面试里我会这样讲：Spring AI 帮我把 Tool Calling 这套链路搭起来了，但真正让它可用的是我对工具暴露范围、参数边界、结果回填和后端强校验的控制。模型负责表达意图，应用负责执行，最终一致性还是得靠后端。

---

相关链接：[[MCP 协议]] | [[Spring AI 核心抽象]] | [[AI Agent 记忆系统]] | [[Spring AI 与我的项目]] | [[苍穹外卖AI客服]]